「現在 AI coding agent 已經可以自己規劃分層、自己決定要不要拆介面，架構師是不是快沒事做了？」
這句話最近常聽到，也不是沒有道理——貼個需求描述給 AI，它確實能生出一個「看起來」有分層的專案骨架：controller、service、repository，一應俱全。如果架構只是「畫出一張長得像分層的圖」，那 AI 早就會了。
但我在這系列想談的架構,不是那種紙上的圖。是當 AI 已經能快速生成程式碼之後，誰來決定它「能改到哪裡、不能碰到哪裡」。這件事，AI 自己回答不了——它沒有立場知道這條邊界該畫在哪，因為畫邊界從來不是技術能力問題，是取捨問題。
AI 越會寫 code，架構的約束力反而越重要——沒有清楚的邊界，AI 會用最短路徑寫出能動但難維護的東西；架構的角色不是規範「怎麼寫」，是限制「能改到哪裡」。
這句話會貫穿接下來 30 天。今天先從一個抽象但具體的情境開始：沒有架構邊界的時候，AI 會怎麼寫。
想像一個很常見的任務：「幫我修一個 bug，某個列表頁在特定條件下會顯示錯誤的金額。」
如果專案裡沒有清楚的分層規則——沒有規定資料查詢要走哪一層、商業邏輯該放在哪、這個頁面能不能直接碰資料庫——AI 會怎麼做？
它會找到問題所在的那個檔案，直接在那個檔案裡修。如果金額計算邏輯散落在畫面渲染的程式碼裡，它就地加一個判斷式；如果需要多查一次資料庫才能算對，它會在同一個檔案裡直接組出查詢並執行。修完之後跑一下測試（如果有的話），綠燈，任務結束。
這個修法沒有錯——它真的修好了那個 bug，而且改動範圍最小、最快看到結果。這正是問題所在：AI 選擇最短路徑不是因為它偷懶或能力不足，而是因為在沒有邊界的情況下，「就地解決」永遠是局部最優解。它沒有理由多繞一層去查「這個系統原本有沒有規定資料查詢該走哪裡」，因為沒有東西告訴它不能這樣做。
一次這樣的修法沒問題。但當這個模式重複一百次、一千次——同樣的金額計算邏輯，散落在十個不同的畫面渲染程式碼裡，各自寫了一份幾乎一樣、又不完全一樣的版本——你會得到一個每個角落都「能動」，但沒有人知道改一個地方會不會漏改另外九個地方的系統。這不是 AI 寫得比人差，是局部合理的選擇，疊加起來變成整體不合理，而這件事，只有架構的邊界能擋住。
在人類主導開發的年代，架構文件很大一部分價值是溝通——讓十個工程師對「這個系統長什麼樣」有共同的心智模型，減少各自猜測造成的落差。這個溝通功能沒有消失，但多了一個更急迫的角色：約束 AI 的改動範圍。
差別在於：人類工程師改程式碼之前，多少會帶著「這樣改合不合理」的直覺去踩剎車——即使沒有文件講清楚規則，資深工程師也會憑經驗猶豫一下。AI coding agent 沒有這種猶豫。它的預設行為是把任務完成、測試綠燈，至於「這樣改會不會破壞這個系統原本想維持的邊界」，它不會主動問，除非有東西明確告訴它「這裡不能這樣做」。
所以架構的角色從「規範怎麼寫比較優雅」，變成「限制能改到哪裡」——具體來說，是把「這個功能的資料存取只能走這一層」「這個模組不能直接依賴那個模組的內部實作」這類規則，變成 AI 動手前就能讀到、動手時會被檢查出違反的東西，而不是只存在資深工程師腦中的默契。
換句話說，架構沒有消失，是從「事後溝通用的圖」變成「事前約束 AI 行為的邊界」。這也是為什麼這系列不會停在畫圖層次的架構討論——後面會具體談 Repository 分層、介面切分、依賴方向、模組邊界這些東西，怎麼從「文件裡的建議」變成「AI 真的會遵守的規則」。
用一組對照具體看這個轉變：
❌ 只存在文件裡、沒有約束力的架構：
架構文件寫著「資料存取要透過 Repository」，
但程式碼裡任何檔案都可以直接組 SQL 丟給資料庫連線。
→ AI 讀不讀那份文件，取決於它有沒有被要求去讀；
就算讀了，沒有東西擋住它「不遵守」的選擇。
✅ 變成邊界、有約束力的架構：
專案規則明講「任何要碰資料庫的程式碼一律經過 Repository」，
且不符合這條規則的程式碼在協作流程裡會被攔下來。
→ AI 就地解決的最短路徑，被迫繞經這一層；
「能改到哪裡」被具體地縮小到一個可預期的範圍。
這兩個版本的差別，不是規則寫得漂不漂亮，而是這條規則有沒有變成 AI 動手時真的會撞到的東西。這正是接下來 29 天要拆解的內容。
回想你手上正在用 AI coding agent 開發的專案：如果現在請 AI 修一個 bug，它有多大機率會找到「原本應該走的那一層」，而不是在離問題最近的地方就地解決？如果答案是「不確定」，那個不確定,本身就是架構邊界不夠清楚的訊號。
明天會把今天的抽象情境變成具體案例：沒有架構邊界時，AI 用最短路徑寫出的程式碼，實際上長什麼樣子。
延伸閱讀：本次鐵人賽同時並行的其他四個系列，會從不同角度處理相關的經驗，有興趣可以一起追：
iThome鐵人賽
看影片追技術